Skunkware 5/Skunkware 5.iso/man/cat.1/term_setup.1

Text File | 1995-07-25 | 9KB | 199 lines

     TTTTEEEERRRRMMMM____SSSSEEEETTTTUUUUPPPP((((1111))))             UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV             TTTTEEEERRRRMMMM____SSSSEEEETTTTUUUUPPPP((((1111))))



     NNNNAAAAMMMMEEEE
          linecheck, test - debugging tools for term

     SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS
          lllliiiinnnneeeecccchhhheeeecccckkkk [ escape ... ] < /dev/tty?? >/dev/tty??

          tttteeeesssstttt [ -d<debug-level> ]

     DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
          You should perform two sets of tests before you ever try to
          run _t_e_r_m itself.  The _l_i_n_e_c_h_e_c_k program performs a first-
          order test of the transparency of the link.  The _t_e_s_t
          program lets you exercise _t_e_r_m and its clients locally by
          starting two _t_e_r_m daemons on the same system.

          _L_i_n_e_c_h_e_c_k sends packets, once per second, each of which
          contains one of the 256 possible 8-bit character codes.  The
          diagnostic output helps you determine which characters do
          not get through.  This is important, since almost all of the
          problems associated with getting _t_e_r_m running occur because
          individual characters or character sequences do not get
          through the serial link or cause other characters to be sent
          and/or echoed by the link.  _T_e_r_m can easily be told to avoid
          sending these characters by listing them in the termrc file,
          the problem is determining which ones to avoid.  _L_i_n_e_c_h_e_c_k
          tests all 256 individual characters and helps you determine
          which are not getting through.  It only checks individual
          characters, not character sequences.

          _L_i_n_e_c_h_e_c_k must be run on both systems the same way _t_e_r_m is
          run.  That is, the stdin and stdout should be directed to
          the serial port while the stderr goes to a log file.
          Remotely you can type

             linecheck 2>/tmp/linecheck.log

          to the sh, or

             sh -c 'exec linecheck 2> /tmp/linecheck.log'

          to the csh.  Locally you should escape from your comm
          program and type something like

             linecheck < /dev/modem > /dev/modem 2> /tmp/linecheck.log

          to a sh.

          You can tell linecheck not to test certain characters by
          listing their decimal numbers on the command line.  For
          instance, if you know flow-control will get eaten, you can
          use "linecheck 17 19", and it won't test those chars.  Or,
          if your link goes through an _r_l_o_g_i_n(1) on the remote end,



     Page 1                                           (printed 7/3/94)






     TTTTEEEERRRRMMMM____SSSSEEEETTTTUUUUPPPP((((1111))))             UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV             TTTTEEEERRRRMMMM____SSSSEEEETTTTUUUUPPPP((((1111))))



          you will want to put 126 on the command line to escape the
          '~' character.  Also, in this case, you'll want to use

             rlogin <system> -8 -L

          in a bid to establish a maximally transparent rlogin.

          Once _l_i_n_e_c_h_e_c_k has finished running on both ends, you should
          examine the respective log files on the two systems.  These
          files will contain lines of the form '<num> sending char'
          and '<num> received valid', where <num> is the decimal
          number of the character in the packet. These indicate that
          the local _l_i_n_e_c_h_e_c_k (the one generating the log file) sent
          the character or received the character from the other
          _l_i_n_e_c_h_e_c_k.  It's normal if the 'sending' and 'received'
          numbers are not in sync.

          Lines of the form 'Invalid packet: <data>' are the
          interesting output.  They indicate a packet was received,
          but was corrupted.  This may be due to simple line noise, or
          to the opacity of the link to a character generated by
          either the remote or the local _l_i_n_e_c_h_e_c_k program.  At least
          three possible kinds of link opacity can lead to invalid
          packets.  When a character that should be be escaped is sent
          the link may simply not transmit the character in question,
          or the link may transmit a different or extra characters.
          Also, at the same time, the link itself may echo characters
          back to the system which sent the character in the first
          place.  You must study the log files from both systems to
          determine which direction of the link causes the problems
          and which characters should be escaped on which system.
          Real link problems like these should be repeatable while
          line noise effects will not.

          The bottom of the log file lists characters that linecheck
          believes should be escaped by the other system in the termrc
          file.  These are characters that the other system sent, but
          which were not received correctly.  If you had no invalid
          packets then this summary is probably reliable.  If there
          were invalid packets it is possible that _l_i_n_e_c_h_e_c_k'_s
          recommendations are wrong.  You must examine both logs
          closely to determine what caused the invalid packets.

          If, for some reason, you get stuck out in lala land, and
          can't kill the remote program, try typing '00000'.  That
          should kill it, and restore your terminal.

          _T_e_s_t, when run, establishes two connected instances of _t_e_r_m
          on the local system so you may see if they and the clients
          work. To avoid problems with other programs also called
          'test' you should run _t_e_s_t from the source directory of _t_e_r_m
          by typing



     Page 2                                           (printed 7/3/94)






     TTTTEEEERRRRMMMM____SSSSEEEETTTTUUUUPPPP((((1111))))             UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV             TTTTEEEERRRRMMMM____SSSSEEEETTTTUUUUPPPP((((1111))))



             ./test [ -d<debug-level> ]

          _T_e_s_t opens the files 'local.log' and 'remote.log' in the
          local directory to record the stderr output of the two term
          daemons.  The -d<debug-level> option sets the debugging
          level for the test.  The termrc file is used to set the
          other parameters of both daemons.  If you need to debug you
          can use 64 or even 478.  Familiarity with the sources is
          essential if you use debugging.

          Once ./test is running you should be able to use the clients
          from any shell:

             trsh

          give you a 'remote' shell.  You may need to type 'reset ^J'
          to reset the tty of the new shell (that's Cntl-J).

             trsh -s who

          will run the who command 'remotely' to list the current
          users.

             tupload -v -f <filename> ... /tmp

          will copy the listed files into the /tmp directory and
          provide CPS statistics.

             tredir 4000 23

          will map port 4000 to 23 and put itself in the background.
          Then, typing

             telnet 0 4000

          should give you a login prompt that works.  If you're
          running X, you should be able to use _t_x_c_o_n_n to establish a
          new display (screen) that maps to the existing screen.

          Be sure to run ./test on both the local and remote systems,
          particularly if the systems use different architectures.

     BBBBUUUUGGGGSSSS
          _L_i_n_e_c_h_e_c_k is too slow.  When run with ./test daemons, the
          _t_r_s_h client may not initialize the 'remote' tty very well.

     SSSSEEEEEEEE AAAALLLLSSSSOOOO
          _t_e_r_m(1), _t_e_r_m__c_l_i_e_n_t_s(1)

     AAAAUUUUTTTTHHHHOOOORRRR
          Michael O'Reilly, [e-mail]




     Page 3                                           (printed 7/3/94)